The management of information in decentralized information networks is important. This is especially true in the management of information and software contained by various mobile devices. Such management of information and files is generally called Device Management. Device Management has the following characteristics, for example: It enables one user application, terminal device or server to remote control at least one other device. It also enables complementing a program or a part thereof in a terminal device by new information or parts of a program, which are located in another device. The validity of licenses, or rights of use, of the software is also managed by it. Device Management may also comprise matters related to Digital Right Management.
Open Mobile Alliance (OMA) has published specifications, which concern the updating and maintenance of software in mobile devices. The specifications OMA DM (Device Management) and OMA DS (Data Synchronization) describe some possible ways of implementing data transfer and real-time maintenance of the files of mobile devices. These specifications also describe the SyncML protocol (Synchronization Markup Language) and how it is utilized.
FIG. 1 presents an exemplary signal chart of the prior art operation in a User Application/Device Management Server/Client Device environment according to the OMA standard. The transfer of instructions and data between the Client Device 11, the Device Management Server 12 and the User Application 13 requires a large amount of message exchange between them. The Device Management Server mentioned below in this description is also referred to by the general name server. The user application 13 can be located either in the server 12 or some third device, which has the right to implement changes in the client device 11. When the user application 13 is located in a third device, the data transfer connection between the user application 13 and the device management server 12 can be a wireless data transfer connection.
Performing a procedure required by a user application 13 in the client device 11 may require executing a number of separate instructions in a certain order. The responsibility for the execution of the instructions lies with the user application 13, which implements the instructions in the client device 11 through the server 12. The client device 11 implements one instruction received at a time and reports on the result to the server 12, which gave the instructions and which transmits the information to the user application 13.
The message exchange can be like the following, for example. Message exchange is started by a user application 13. In the example of FIG. 1, the user application 13 requires the performance of certain procedures in the client device 11. The procedures are implemented by sending a certain number of instructions, like m instructions in the example of FIG. 1.
The user application 13 sends the first instruction, Ref. 14a, to the server 12. The server transmits the instruction it has received to the client device 11 for execution, Ref. 14b. After the execution of the instruction, the client device 11 sends the execution information, Ref. 15a, of the result of the operation back to the server 12, which transmitted the instruction. The server 12 transmits the performance information it has received further to the user application 13, Ref. 15b. If the first instruction has been executed successfully, the user application 13 sends the next instruction to the server 12, Ref. 16a. The server 12 transmits the instruction it has received further to the client device 11 for performance, Ref. 16b. The client device 11 executes the second instruction it has received and sends execution information of the execution of the second instruction back to the server 12. The server 12 transmits the execution information it has received in the manner described above to the user application 13.
The user application 13 must always check the content of each piece of execution information it has received, in order to be able to proceed in the instruction sequence to the execution of the next instruction. The execution information received from the client device 11 may thus also result in that the user application 13 must make a decision on which instruction is transmitted to the client device next.
The user application 13 may also report to the requester of the instruction sequence, which may be a physical client, after each instruction executed.
The message exchange lasts until the user application 13 sends the last instruction belonging to the sequence of instructions through the server 12 to the client device 11, Refs. 17a and 17b. The execution information of the last instruction is returned by message 18a to the server 12, which transmits it further to the user application, Ref. 18b. If the message indicates that the execution of the last instruction was also successful, the message exchange between the user application 13, server 12 and client device 11 is stopped.
A central problem in wireless data transfer is the limited data transfer channel used. The prior art conversation between the user application, server and client device for executing the sequence of instructions consumes the limited data transfer resources of the wireless system unnecessarily.